C++ and Structured Exception Handling

RTX64 supports Microsoft C++ exceptions (catch/throw), Windows Structured Exception Handling (SEH) API, and C frame-based exception handling (try/except/finally), all as defined by the Windows Platform SDK.

This topic discusses:

• C++ Support
• Structured Exception Handling
• Differences Between Windows and RTSS Exception Handling
• General User Notes for Exception Handling

NOTE: For more information on the APIs referenced in this chapter, see the RTX64 SDK Help.

C++ Support

RTX64 supports the Visual C++ language, with some restrictions discussed in the note below. RTSS supports all C++ features usable in a Windows C++ RTX64 API console application, including new/delete operators and exception handling.

NOTE: RTX64 does not claim support for all C++ libraries. Support is limited to libraries that depend upon the set of Windows functions supported in the RTSS environment. See the Matrix of C++ Standard Template Library Calls for more information.

Structured Exception Handling

RTSS supports Structured Exception Handling and C++ exceptions, as described by the Windows Platform SDK, including:

• Windows Structured Exception Handling calls, which include RaiseException, SetUnhandledExceptionHandler, UnhandledExceptionFilter, AbnormalTermination, GetExceptionCode, GetExceptionInformation
• Frame-based exception handlers: try-except and try-finally.
• C++ exception handling: try-catch.
• Handling for the following software exceptions in RTSS:

EXCEPTION_DATATYPE_MISALIGNMENT
EXCEPTION_BREAKPOINT
EXCEPTION_SINGLE_STEP
EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLT_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERFLOW
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_INT_DIVIDE_BY_ZERO

Using Structured Exception Handling

To use Stuctured Exception Handling (SEH) in an RTSS application, the application must be linked with the Microsoft C Runtime libraries which contain run-time support for the SEH frame-based exception handlers.

Differences Between Windows and RTSS Exception Handling

The RTSS implementation follows Windows SEH semantics where possible. This section describes the differences.

UnhandledExceptionFilter

Windows UnhandledExceptionFilter semantics provide the option to disable the exception-related dialog box pop-up via SetErrorMode with the SEM_NOGPFAULTERRORBOX flag. On an exception, RTSS always displays a pop-up saying that the application has been frozen or unloaded.

Exception caused by a thread

When a thread of a multithreaded application causes an exception in Windows, the system displays a dialog box. Until the user responds to the box, other threads of the application continue running. Once the user has responded, all threads of the application terminate.

RTSS acts differently; it freezes (or unloads, depending on how the subsystem is configured in the Control Panel) all threads of a process whenever any of them gets an exception, and produces an informational pop-up. This behavior is safer and more intuitive in the RTSS context. You can, however, emulate the Windows behavior by using per-thread unhandled exception filter functions.

Nested exceptions and collided unwinds

RTSS follows Windows rules for nested exceptions and "collided" unwinds, with a few minor differences:

• Non-continuable exceptions — Non-continuable exceptions caused by the program directly or by exception handling run-time itself. Windows repeatedly re-asserts those; but repeated re-assertion of exceptions consumes stack space. A stack fault in RTSS causes a system shutdown (the "green screen"), so for robustness, RTSS terminates a process that has generated a non-continuable exception.
• Hardware exceptions — RTSS exception codes for hardware exceptions are tied to Pentium interrupt codes, thus differing from Windows exception codes caused by similar errors. For example, an errant Windows application gets an EXCEPTION_ACCESS_VIOLATION as defined by Windows, an RTSS application gets EXCEPTION_PAGE_FAULT as described in the RTX64 Reference Guide. A Windows EXCEPTION_ILLEGAL_INSTRUCTION is equivalent to the RTSS EXCEPTION_INVALID_OPCODE.
• Reads/writes of address 0 — Windows explicitly guarantees that the first 64K of a user process's address space is unmapped, so any access of that area causes an exception. However, Windows occasionally makes this area valid for kernel processes and device drivers (and, therefore, for RTSS).

General User Notes for Exception Handling

• Exception handling is a powerful mechanism with often subtle semantics. It is quite easy to write code that causes infinite re-assertion of an exception. For example, if a filter expression always faults, or always dismisses a hardware exception which gets re-executed, the process continues generating exceptions until it overflows the stack. Miscasting the handler argument to SetUnhandledExceptionFilter may be equally fatal.
• Because stack faults in RTSS cause system shutdown, you must be careful when writing exception handlers. Testing your application in Windows is recommended, to avoid stack overflows in RTSS.
• To modify the behavior of how RTX64 treats exceptions, use the Control Panel.
• If RTSS Structured Exception Handling (SEH) wants to access and modify floating point registers within the CONTEXT record, the SEH filter and except body should access and modify the ExtendedRegisters field of CONTEXT, not the FloatSave field of CONTEXT. The format of ExtendedRegisters is of the XSAVE_FORMAT, which is available in winnt.h.